home
***
CD-ROM
|
disk
|
FTP
|
other
***
search
/
kermit.columbia.edu
/
kermit.columbia.edu.tar
/
kermit.columbia.edu
/
newsgroups
/
misc.19950329-19950528
/
000127_news@columbia.edu_Thu Apr 13 06:48:34 1995.msg
< prev
next >
Wrap
Internet Message Format
|
1995-07-31
|
4KB
Received: from apakabar.cc.columbia.edu by watsun.cc.columbia.edu with SMTP id AA01884
(5.65c+CU/IDA-1.4.4/HLK for <kermit.misc@watsun.cc.columbia.edu>); Thu, 13 Apr 1995 16:08:56 -0400
Received: by apakabar.cc.columbia.edu id AA26400
(5.65c+CU/IDA-1.4.4/HLK for kermit.misc@watsun); Thu, 13 Apr 1995 16:08:53 -0400
Path: news.columbia.edu!panix!news.mathworks.com!udel!gatech!concert!ais.com!bruce
From: bruce@ais.com
Newsgroups: comp.protocols.kermit.misc
Subject: Re: too slow!
Message-Id: <1995Apr13.114834.7576@ais.com>
Date: 13 Apr 95 11:48:34 EST
References: <3ma7sh$h83@news.csus.edu>
Organization: Applied Information Systems, Chapel Hill, NC
Lines: 66
Apparently-To: kermit.misc@watsun.cc.columbia.edu
In article <3ma7sh$h83@news.csus.edu>, sac87574@saclink1.csus.edu (Scott Hanson) writes:
> It could be my ignorance talking, but kermit is the only file transfer my
> server has..I've tried raising packet size, opening more windows, and
> basically everything I can think of without guidance to speed things
> up..Why would anyone want to use this program? A 100,000 byte program
> can take 10 minutes? It's ridiculous!
On a connection at 9600 baud or above, this is a rather long time for
Kermit to transfer the file. Using Kermit over a 9600 baud modem, I
usually get transfers of 100K files taking under 2 minutes (around 900
bytes/sec or so). You need to raise the packet size and increase the
number of windows, and preferably also use 8-bit transfers if possible.
My guess is that either you haven't increased the parameters on _both_
the client and the server (most Kermit implementations need to have
these parameters increased on both sides since the default values are
very conservative and setting them on the client doesn't make it
request the change in the server as well - it just causes them to
negotiate the minimum values between them, which in that case would
probably be the server's default values, and which are most likely
not very efficient); or that your complete connection isn't as fast
as you think it is (for example, there is a modem or machine in the
middle somewhere that is a bottleneck and not letting more than about
200 bytes/sec through -- a 2400 baud modem, perhaps? That can appear
to be faster than 2400 baud for simple text if it has V.42 bis data
compression, but would seem to slow down remarkably for compressed
binary transfers).
If the problem is the latter, then your only solutions would be to
replace the offending hardware or to find another circuit to the host
that avoids using it. Moving to another protocol won't help much;
properly configured, Kermit and ZModem are within a few % (single
digits) of each other. (Kermit's biggest advantage is its ability
to work over a much wider variety of host/client/circuit combinations).
For sites where I do a lot of transfers, I prefer to put my usual
settings in the appropriate .INI file, which saves a certain amount
of typing on startup. For example, one CKERMIT.INI file I use for
C-Kermit on several VMS systems that I regularly transfer files
between is:
set block 3
set send packet 1000
set receive packet 1000
set window 2
set terminal byte 8
set comm byte 8
set file type label
Note that to be effective this has to be used on both sides!! Also
note that it won't work for transferring files to/from PC's or Unix
boxes unless you remove the `set file type label' line, and that the
other parameters may or may not work (or be optimal if they do work)
for your particular connection. 8-bit transfers in particular may
fail on some machines that use only 7-bit ASCII, and on some circuits
which include slow machines between the two endpoints, packets this
long may cause characters to be dropped. Some half-duplex circuits
may also not permit multiple windows to be used effectively. For
what it's worth, I can configure Kermit to get around these problems
but ZModem does not appear to be able to do so (although if the
circuit is completely clean it is perhaps very fractionally faster,
but about the only way you can tell for sure is with a stopwatch).
Good luck,
Bruce C. Wright